System upgrades can be a complex process requiring much planning. Typically, system upgrades are performed to replace failing hardware or to take advantages of new or enhanced features of current hardware. The new or enhanced features may come in the form of hardware, software or a combination of both hardware and software. One important requirement to be addressed in performing system upgrades is compatibility of the new hardware with the existing hardware and software in the system. Planning for system upgrades is an activity that can consume time and resources. Often documentations are meticulously prepared and followed to avoid potential negative impact on the system.
For example, in the MGX 8850 switch manufactured by Cisco Systems of San Jose, Calif., there can be up to 12 ATM Switching Modules (AXSM) and two Processor Switching Modules (PXM) on multiple slots in a single shelf. The Processor Switching Module (PXM) is referred to as the control module. Within a shelf, in addition to the control module, there are other modules referred to as service modules. Each service module generally comes in a card set that consists of a front card (with its attached daughter card) and one or two back cards (or line modules). The front card contains the processing intelligence and, on the daughter card, the firmware that distinguishes the interface (e.g., OC-48, OC-3, T3, E3, etc.). The service modules interact with each other using a shared bus. FIG. 1 is a block diagram illustrating an example of a communication module. The communication module 100 includes a control module 130 and several service modules 110-125. The control module 130 is connected with the service modules 120, 125 through a shared bus 105. The control module 130 is connected with the service modules 110, 115 through the shared bus 102. Each of the service modules 110-125 may be configured to process a type of traffic (e.g., Frame Relay, Voice, Asynchronous Transfer Mode (ATM), T1/E1, etc.). In addition to connecting with multiple shared buses 102, 105 to the multiple service modules (e.g., service modules 110-125), the control module 130 may also be connected with a high bandwidth bus 135 (e.g., OC-12, OC-3) to a core network and other core nodes (not shown). Similar to the service modules, the control modules also have front cards and back cards.
The control module and each of the service modules has an associated hardware revision. Furthermore, the control module and each of the services modules has an associated boot firmware revision and runtime firmware revision. Because each of the hardware, boot firmware and runtime firmware has a separate revision, it is important that any upgrade to the hardware revision, boot firmware revision, and runtime revisions in a module are compatible with one another. For example, there is a hardware compatibility requirement that when one module (e.g., control or processor module) is running at a particular hardware revision, each of the other modules (e.g., service modules) also has to run at an equivalent revision. In addition to the compatibility requirement on a single module, there is also a compatibility requirement across the modules. For example, there may be a software compatibility requirement such that when the control module is running with a particular software revision, each of the associated service modules also has to run with a compatible software revision.
Currently, compatibility is addressed by preparing compatibility documentations that specifically list compatibility information (e.g., in tables or matrices) to enable the end users to manually use the compatibility information and select the appropriate hardware and/or software revisions that satisfy the compatibility requirement. FIG. 2 illustrates prior art examples of an upgrade matrix and a downgrade matrix used for a Cisco MGX 8220 switch. There may be different upgrade procedures and downgrade procedures that the end users have to follow depending on the operation.
Referring to the examples in FIG. 2, to perform an ungraceful upgrade (205) from version 2.x to version 3.x, the upgrade procedure number one is to be followed. However, to perform a downgrade (210) from version 4.x to another version 4.x, the upgrade procedure number nine is to be followed, etc. Furthermore, with each upgrade procedure, the end user has to issue commands at the system to verify correct existing revision information. Each procedure may require a different number of steps that the end user has to go through. For example, the procedure number one requires 14 steps to complete, while the procedure number nine requires 13 steps. With each new release of a component, the requirement for compatibility and risk of errors increase. Although FIG. 2 includes examples that refer to the Cisco MGX 8220 switch, similar methods are used to perform upgrades and/or downgrades for other switches. Even with detailed compatibility documentation, the risk of the end users installing an incompatible hardware still exists.
Because compatibility is critical for all upgrades, downgrades and system maintenance, it is important to verify that compatibility exists for hardware revisions as well as software revisions prior to experiencing any problems relating to incompatibility. When an installed hardware component is incompatible with the rest of the system, the system may not operate optimally (e.g., disruption to network traffic, degradation of performance, etc.). Accordingly, it is advantageous to be able to perform compatibility verification without suffering from the limitations of the current method.